This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @chemamartinez? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v8./d.0 is the label to automatically backport to the 8./d branch. /d is the digit

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b fix-httpjson-parseDate-timezone upstream/fix-httpjson-parseDate-timezone
git merge upstream/main
git push upstream fix-httpjson-parseDate-timezone

❕ Build Aborted

There is a new build on-going so the previous on-going builds have been aborted.

the below badges are clickable and redirect to their specific view in the CI or DOCS

Steps errors

🤖 GitHub comments

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

I'm not convinced that this is the right solution. If we cannot parse the timezone because it is incorrectly using a non-IANA tzdb label or absolute fixed timezone, it should be set in the UI config.

@efd6 thanks for taking a look!

Since this is fixing a value template, that parses dates that can come from anywhere at any timezone, how would we set the timezone in the UI config? Do you mean forcing users that use this value template to define what's the timezone of the incoming dates?

On the other hand, do you see any particular issue that makes this change undesirable? I agree this may not be the optimal solution, even the Go developers seem to have been debating the issue for quite some time:
golang/go#56528
golang/go#63345
For now, if no native solution is provided, the time.Parse docs suggests using ParseInLocation when facing this kind of issues, and it works at least for the most common cases.

Please let me know your thoughts about this. Thanks!

The commentary in go.dev/issue/63345 goes over the issues with this very nicely and explains exactly why this is undesirable. The caveat in the final paragraph of time.Parse is also informative about why this is a dangerous action to take (briefly, if the agent is running in a location that does not know the abbreviation, the tzoffset will be zeroed, or worse if it is in another location where the abbreviation means something else it will be definitively incorrect).

In practice any particular instance of HTTPJSON would likely only be collecting data from a single tz, so if this is not parseable, a single configuration location would be enough to specify that time be handled in that singular location. Maybe it would be helpful to have a parseTimeInLocation template helper.

If this change here is added, it needs documentation making the sharp edges clear and suggesting that users configure time-offset timezone specs if possible.

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b fix-httpjson-parseDate-timezone upstream/fix-httpjson-parseDate-timezone
git merge upstream/main
git push upstream fix-httpjson-parseDate-timezone

💚 Build Succeeded

• Buildkite Build
• Commit: b767c90

cc @chemamartinez

💚 Build Succeeded

• Buildkite Build
• Commit: b767c90

cc @chemamartinez

💚 Build Succeeded

• Buildkite Build
• Commit: b767c90

cc @chemamartinez

💚 Build Succeeded

• Buildkite Build
• Commit: b767c90

cc @chemamartinez

In practice any particular instance of HTTPJSON would likely only be collecting data from a single tz, so if this is not parseable, a single configuration location would be enough to specify that time be handled in that singular location. Maybe it would be helpful to have a parseTimeInLocation template helper.

If this change here is added, it needs documentation making the sharp edges clear and suggesting that users configure time-offset timezone specs if possible.

@efd6 I added a new value template parseDateInTZ and updated the docs intending to clarify edge cases and this timezone issue. Regarding the implementation of parseDateInTZ, I had two different approaches depending on what we would prefer:

1. Using time.ParseInLocation gives preference to the implicit timezone in the provided date over the specified timezone.
2. Using time.Parse after a manual assignment of the location. That way we prioritize the given one.

I chose the last option, let me know if you have second thoughts on this.

💚 Build Succeeded

• Buildkite Build
• Commit: b767c90

cc @chemamartinez

💚 Build Succeeded

• Buildkite Build
• Commit: b767c90

cc @chemamartinez

I chose the last option

I agree.